Bookmark this page as https://g.co/chrome/root-policy
Google Chrome relies on Certification Authority systems (herein referred to as "CAs") to issue certificates to websites. Chrome uses these certificates to help ensure the connections it makes on behalf of its users are properly secured. Chrome accomplishes this by verifying that a website's certificate was issued by a recognized CA, while also performing additional evaluations of the HTTPS connection's security properties. Certificates not issued by a CA trusted by Chrome or a user's local settings can cause users to see warnings and error pages.
When making HTTPS connections, Chrome refers to a list of self-signed root certificates from CAs that have demonstrated why continued trust in them is justified. This list is known as a "Root Store." CA certificates included in the Chrome Root Store are selected on the basis of publicly available and verified information, such as that within the Common CA Database (CCADB), and ongoing reviews by the Chrome Root Program.
The Chrome Root Program Policy below establishes the minimum requirements for CA certificates to be included as trusted in a default installation of Chrome.
The Chrome Root Program continuously evolves this policy to enhance the security and resilience of the Internet ecosystem, consistent with Google's ongoing commitment to secure and reliable network connections in Chrome. This involves establishing and periodically strengthening minimum requirements for CAs. New requirements, sometimes only for Applicants, are introduced to progressively raise the baseline of trust and drive the adoption of modern, agile, and secure Public Key Infrastructure (PKI) practices. This phased approach allows the program to integrate advancements and best practices, ensuring that certificates included in the Chrome Root Store consistently provide value to Chrome end users that exceeds the risk of their continued inclusion, while accounting for the practicalities of protecting users at scale. Aspects of value are principally demonstrated through the real-world use of the corresponding root CA certificate. This includes active TLS server authentication certificate issuance, observability of time-valid and unrevoked TLS server authentication certificates across the Internet, and direct reliance on those certificates by the Chrome Certificate Verifier when securing Chrome user connections.
Except in the case of CA Owners applying for inclusion, this policy makes no stipulation on the characteristics or PKI use cases served by CAs not included in the current version of the Chrome Root Store.
Any questions regarding this policy can be directed to chrome-root-program [at] google [dot] com.
CA Owners that satisfy the requirements defined in the policy below may apply for self-signed root CA certificate inclusion in the Chrome Root Store using these instructions.
Applicants are expected to continuously adhere to the policies outlined herein, irrespective of their inclusion request submission date. All Applicants are expected to satisfy the requirements set forth in both the "Minimum Requirements for CAs included in the Chrome Root Store" and "Minimum Requirements for Applicant CAs Requesting Inclusion into the Chrome Root Store" Sections. Where requirements in these sections differ, the Applicant-specific requirements take precedence.
If an Applicant's Root Inclusion Request is currently in the CCADB with a status of 'Verification By Root Store' and has not yet received a final determination, and this policy is updated to a new version, the Chrome Root Program will change the request's status to 'CA Providing Data.' Applicants must review and ensure compliance with the updated policy expectations before resubmitting their Root Inclusion Request for review by the Chrome Root Program.
The Chrome Root Program and corresponding policy represent Google's ongoing commitment to upholding secure and reliable network connections in Chrome.
In support of this commitment, Google, as it deems appropriate and at its sole discretion:
Chrome maintains a variety of mechanisms to protect its users from certificates that put their safety and privacy at risk, and is prepared to use them as necessary. A Chrome Root Program Participant's failure to follow the minimum requirements defined in this policy may result in the corresponding certificate's removal from the Chrome Root Store, limitations on Chrome's acceptance of the certificates they issue, or other technical or policy restrictions. Before taking such action, the Chrome Root Program always evaluates the broader context of an individual incident and considers it against the factors significant to the Chrome Root Program.
The "Moving Forward, Together" initiative envisions a future Internet ecosystem that includes modern, reliable, highly agile, purpose-driven PKIs with an emphasis on automation, simplicity, and security.
Learn more about priorities and initiatives that may influence future versions of this policy here. Please note "Moving Forward, Together" is future looking and does not describe normative requirements.
If you're a Chrome user experiencing a certificate error and need help, please see this support article.
If you're a website operator, you can learn more about why HTTPS matters and how to secure your site with HTTPS. If you've got a question about a certificate you've been issued, please contact the CA that issued it.
If you're responsible for a CA that is not trusted by default in Chrome and only issues certificates to your enterprise organization, sometimes called an "enterprise", "private" or "locally trusted" CA, the Chrome Root Program Policy does not apply to or impact your CA's PKI use cases. Enterprise CAs are used for issuing certificates to internal resources like intranet sites or applications that do not directly interact with external users of the public Internet (e.g., a TLS server authentication certificate issued to a corporate intranet site).
Though uncommon, websites can also use certificates to identify clients (e.g., users) connecting to them. Besides ensuring it is well-formed, Chrome passes this type of certificate to the server, which then evaluates and enforces its chosen policy. The policies on this page do not apply to client authentication certificates.
Learn more about the Chrome Root Store and Chrome Certificate Verifier here.
This policy, along with archived versions, is available in Markdown here.
| Version | Date | Note |
|---|---|---|
| 1.8 | 2026-02-05 | Updates include, but are not limited to: (1) limiting the number of root certificates per CA Owner included in the Chrome Root Store, (2) extending automation support requirements from Applicants to all existing CAs trusted by Chrome, (3) requiring CA policy documents to state adherence to the Chrome Root Program Policy, (4) setting expectations for industry engagement, (5) recommending practices for Subordinate CA lifecycle management, (6) encouraging support for the Certificate Transparency ecosystem, and (7) consolidating all requirements applicable only to Applicants in a dedicated section |
| 1.7 | 2025-07-15 | Updates include, but are not limited to: (1) add the ARI RFC numerical identifier, (2) remove requirements redundant with CCADB Policy Version 2.0 |
| 1.6 | 2025-02-15 | Updates include, but are not limited to: (1) the future phase-out of non-TLS server authentication dedicated hierarchies from the Chrome Root Store, (2) requirements for future Applicants related to automation support, promoting simplicity of policy documents, and the definition of a dedicated TLS server authentication PKI hierarchy, (3) improved alignment with the TLS Baseline Requirements following Ballot SC-077, (4) addition of subsection numbers and major reorganization of normative and non-normative requirements |
| 1.5 | 2024-01-16 | Updates include, but are not limited to: (1) incorporated CA Owner feedback in response to policy Version 1.4 (clean-ups and clarifications throughout the policy), (2) added new subsections for Root CA Key Material Freshness, Automation Support, and the Root CA Term-Limit, (3) aligned incident reporting format and timelines with CCADB.org |
| 1.4 | 2023-03-03 | Updates include, but are not limited to: (1) alignment with CCADB Policy Version 1.2 and the Baseline Requirements, (2) clarify requirements related to the submission of annual self-assessments, (3) clarify requirements to better align with program intent (e.g., CA Owner policy document freshness), (4) updated audit and incident reporting requirements to promote increased transparency, (5) require subordinate CA disclosures in CCADB, (6) clarify CA certificate issuance notification requirements |
| 1.3 | 2023-01-06 | Updated to include the CCADB Self-Assessment |
| 1.2 | 2022-09-01 | Updated to reflect the launch of the Chrome Root Program. Updates include, but are not limited to: (1) removal of pre-launch discussion, (2) clarifications resulting from the June 2022 Chrome CCADB survey, (3) minor reorganization of normative and non-normative requirements |
| 1.1 | 2022-06-01 | Updated in anticipation of the future Chrome Root Program launch. Updates include, but are not limited to: (1) future-dated Applicant requirements for dedicated TLS-hierarchies and key-pair freshness, (2) clarification of audit expectations, (3) requirements for cross-certificate issuance notification, (4) description of and requirements related to an annual self-assessment process, (5) an outline of priority Chrome Root Program initiatives |
| 1.0 | 2020-12-20 | Initial release |
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this policy are to be interpreted as described in RFC 2119.
This policy considers a "CA Owner" to be the organization or legal entity that is either:
This policy considers an "Applicant" to be an organization or legal entity that has an open "Root Inclusion Request" submitted to Google Chrome in the CCADB.
This policy uses the term "Chrome Root Program Participants" to describe:
This policy uses the term "Externally-operated CA" to describe a subordinate CA certificate issued where the organization or legal entity in possession or control of the corresponding private key capable of issuing new certificates is not under the sole control of the CA Owner whose certificate is included in the Chrome Root Store.
This policy considers a PKI hierarchy as "dedicated" if it is intended to serve one specific use case, for example, the issuance of TLS server authentication certificates.
To continually raise the baseline of trust and drive the adoption of modern, agile, and secure PKIs, this policy sometimes "phases out" practices (sometimes referred to as a "phase-out"). Unless otherwise specified, phase-outs are accomplished using an SCTNotAfter constraint on a corresponding root CA’s certificate included in the Chrome Root Store. TLS server authentication certificates issued on or before a practice’s or PKI hierarchy’s specified phase-out date and time will be trusted in Chrome until expiry, whereas certificates issued after will not be trusted by default. The corresponding root CA’s certificate included in the Chrome Root Store will be removed upon the absence of unexpired and unrevoked TLS server authentication certificates issued prior to the phase-out date.
The following requirements are effective immediately, unless explicitly stated as otherwise.
Chrome Root Program Participants MUST satisfy the requirements defined in this policy, including taking responsibility for ensuring the continued compliance of all corresponding subordinate CAs and delegated third parties participating in the PKI.
Chrome Root Program Participants that issue TLS server authentication certificates trusted by Chrome MUST adhere to the latest version of the "Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates" ("Baseline Requirements"). The Baseline Requirements are consensus-driven requirements owned by a community of participants represented in the CA/Browser Forum Server Certificate Working Group. No single organization, including Google, has the authority to grant exceptions to the Baseline Requirements.
In some cases, this policy strengthens requirements described in the Baseline Requirements.
The Chrome Root Program relies on the CCADB to identify and maintain up-to-date information for Chrome Root Program Participants and the corresponding PKI hierarchies.
Chrome Root Program Participants MUST adhere to the latest version of the CCADB Policy.
In some cases, this policy strengthens requirements described in the CCADB Policy.
Effective June 15, 2026, a Chrome Root Program Participant's CP or combined CP/CPS MUST explicitly state adherence to the latest published version of this policy and the CCADB Policy. This attestation SHOULD be made in Section 1.1 ("Overview").
If a CA Owner already has two (2) or more self-signed root CA certificates included in the Chrome Root Store, the Chrome Root Program will only accept a new CCADB Root Inclusion Request to replace an existing certificate (i.e., 'one in, one out').
Before June 15, 2026, CA Owners with more than two (2) self-signed root CA certificates in the Chrome Root Store MUST submit a written consolidation plan to the Chrome Root Program. This plan MUST:
Effective September 15, 2027, the Chrome Root Store will only include a maximum of two (2) self-signed root CA certificates per CA Owner. PKI hierarchies being phased-out are not counted toward this limit.
To further reduce negative impact to the ecosystem, the Chrome Root Store may temporarily continue to include more than two (2) self-signed root CA certificates past the specified consolidation timeline on a case-by-case basis.
CA Owners SHOULD request for the replacement of a certificate included in the Chrome Root Store no later than five (5) years after the release date of the Chrome Root Store's initial inclusion of the certificate.
Before a CA Owner submits a Root Inclusion Request to the CCADB, it MUST have issued a cross-certificate from the CA being replaced to the replacement CA. Due to the existence of the cross-certificate, TLS server authentication certificates issued by the replacement PKI hierarchy will be trusted by default in versions of Chrome relying on the Chrome Root Store, regardless of whether they are capable of receiving updates to the Chrome Root Store.
Within no more than 90 calendar days after a replacement CA certificate being first distributed by the Chrome Root Store and as disclosed in the CCADB, the CA Owner MUST have transitioned all TLS server authentication certificate issuance intended to be trusted by default in Chrome from the cross-signing PKI hierarchy to the replacement PKI hierarchy. To technically enforce this transition, the CA being replaced will have a phase-out date set to 90 calendar days after the Applicant CA certificate being first distributed by the Chrome Root Store. While the CA Owner is not prohibited from continuing to issue certificates from the PKI hierarchy being replaced after this phase-out date, such certificates will not be trusted by default in Chrome. The CA certificate being replaced will be removed from the Chrome Root Store upon the absence of unexpired and unrevoked TLS server authentication certificates (excluding test certificates like those disclosed to the CCADB) disclosed to Certificate Transparency (CT) before this phase-out date.
Any root CA certificate with corresponding key material generated more than 15 years ago will be removed from the Chrome Root Store on an ongoing basis.
The age of the key material will be determined by the earliest of either:
To phase-in these requirements in a manner that reduces negative impact to the ecosystem, affected root CA certificates included in the Chrome Root Store will be removed according to the schedule in the table below.
| Key Material Created | Approximate Removal Date |
|---|---|
| Between January 1, 2006 and December 31, 2007 (inclusive) | April 15, 2026 |
| Between January 1, 2008 and December 31, 2009 (inclusive) | April 15, 2027 |
| Between January 1, 2010 and December 31, 2011 (inclusive) | April 15, 2028 |
| Between January 1, 2012 and April 14, 2014 (inclusive) | April 15, 2029 |
| After April 15, 2014 | 15 years from generation |
To further reduce negative impact to the ecosystem, the Chrome Root Store may temporarily continue to include a root CA certificate past its defined term-limit on a case-by-case basis, if the corresponding CA Owner has submitted a Root Inclusion Request to the CCADB for a replacement root CA certificate at least one (1) year in advance of the approximate removal date.
Other circumstances may lead to the removal of a root CA certificate included in the Chrome Root Store before the completion of its term.
The lifecycle management of subordinate CA certificates plays a crucial role in promoting agility and resilience within the ecosystem. By setting clear expectations for their validity and renewal, the Chrome Root Program aims to align certificate profiles with modern best practices, reduce reliance on specific subordinate CA certificates that could be single points of failure, and discourage potentially harmful practices. This approach allows the ecosystem to benefit from continuous improvement efforts.
To achieve these goals, it's encouraged that all subordinate CA certificates that validate to a certificate included in the Chrome Root Store align with the following practices:
The Chrome Root Store is solely relied upon for TLS server authentication in Chrome; it is not used for any other PKI use case (e.g., TLS client authentication, secure email, code-signing, etc.).
To align all PKI hierarchies included in the Chrome Root Store on the principle of serving only TLS server authentication use cases, the Chrome Root Program will phase-out multi-purpose roots from the Chrome Root Store.
Beginning June 15, 2026, the Chrome Root Program will phase-out PKI hierarchies found in violation of the below requirements. In these cases, the phase-out date will be set to 90 calendar days following the violation’s detection.
To reduce negative impact to the ecosystem, the Chrome Root Store may temporarily continue to include a multi-purpose root CA certificate in the Chrome Root Store without an SCTNotAfter constraint on a case-by-case basis, but only if the corresponding CA Owner has submitted a Root Inclusion Request to the CCADB for a replacement root CA certificate before June 15, 2026.
Certificate lifecycle management automation solutions ("automation solutions") increase agility and improve the security and resilience of the Internet ecosystem. Automation solutions minimize "hands-on" input required from humans during certificate issuance and renewal. Routine certificate issuance and renewal SHOULD NOT involve human input except as needed for identity or business document verification related to IV, OV, or EV certificate issuance.
Effective March 15, 2027, all unexpired and unrevoked subordinate CA certificates signed by a root CA certificate included in the Chrome Root Store MUST be integrated with an automation solution, minimally compliant with either Section 1.3.3.1.1 ("ACME Solutions") or Section 1.3.3.1.2 ("Non-ACME Solutions"). Functionally, this means that every TLS server authentication certificate profile offered by a subordinate CA trusted in Chrome MUST be capable of being issued and renewed using an automation solution. CA Owners MUST attest that this requirement is met for each Baseline Requirements certificate policy OID the corresponding PKI hierarchy issues through a disclosure in the CCADB on the root certificate record of each CA included in the Chrome Root Store.
Additionally, effective March 15, 2027, for each CCADB root certificate record corresponding to a root included in the Chrome Root Store, CA Owners MUST disclose at least one (1) automation solution for each Baseline Requirements certificate policy OID appearing in unexpired and unrevoked subscriber certificates. For each such OID, the CA Owner MUST use a disclosed automation solution to issue "Automation Test Certificates" to demonstrate its automation capabilities. Automation Test Certificates MUST be renewed at least once every 30 calendar days; however, at any point, the Chrome Root Program may request more frequent renewal. At least one (1) valid Automation Test Certificate corresponding to each Baseline Requirements certificate policy OID MUST be served by a publicly accessible website whose URL is disclosed to the CCADB on the corresponding intermediate certificate record. CA Owners are encouraged to issue "Short-lived Subscriber Certificates," as introduced in Version 2.0.1 of the Baseline Requirements, for the Automation Test Certificates.
The above requirements do not:
Beginning March 15, 2027, the Chrome Root Program will phase-out PKI hierarchies found issuing new certificates containing a Baseline Requirements certificate policy OID lacking an automation solution attestation disclosure in the CCADB. In these cases, the phase-out date will be set to 90 calendar days following the violation’s detection.
PKI hierarchies SHOULD support the Automatic Certificate Management Environment (ACME) protocol. If ACME is supported:
While ACME support is encouraged, PKI hierarchies MAY support other automation solutions so long as the following characteristics are verifiably demonstrated to the Chrome Root Program. If the requirements in Section 1.3.3.1.1 ("ACME Solutions") are not met, the CA Owner MUST disclose to the CCADB publicly available information that describes the other automation solution capability for each Baseline Requirements certificate policy OID that the corresponding PKI hierarchy issues and how a subscriber can leverage its benefits. For the purposes of this section, an "automation solution" is defined as the combination of the CA’s issuance interface (e.g., API) and compatible client software provided and maintained directly by the CA Owner that is ultimately operated by the TLS server authentication certificate requestor. This client software SHOULD be comparable in function and operation to an ACME client, and MAY be incorporated into Certificate Lifecycle Management tooling.
The automation solution MUST:
The automation solution SHOULD:
CA Owners with CA certificates that validate to a certificate included in the Chrome Root Store SHOULD ensure that all TLS server authentication precertificates issued by such CAs are logged to at least one (1) CT log recognized by Chrome as Usable or Qualified within 24 hours of issuance.
Effective June 15, 2026, CA Owners with CA certificates that validate to a certificate included in the Chrome Root Store MUST ensure that all TLS server authentication precertificates issued by such CAs are logged to at least one (1) CT log recognized by Chrome as Usable or Qualified before issuing the corresponding certificate.
CA Owners with CA certificates that validate to a certificate included in the Chrome Root Store SHOULD ensure that all TLS server authentication certificates (i.e., "final certificates") issued by such CAs are logged to at least one (1) CT log recognized by Chrome as Usable or Qualified within 24 hours of issuance.
Chrome Root Program Participants SHOULD contribute to the health and diversity of the CT ecosystem. Such contributions may include, but are not limited to:
Chrome Root Program Participant CAs MUST be audited in accordance with the table below.
Audits MUST NOT rely on a version of the accepted audit criteria below if it has been superseded by more than 30 calendar days before the start of the corresponding audit period.
| CA Type | EKU Characteristics** | Audit Criteria |
|---|---|---|
| Root CA | N/A | If WebTrust scheme… (1) "WebTrust Principles and Criteria for Certification Authorities"; and either… - (A) "WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security" or - (B) "WebTrust Principles and Criteria for Certification Authorities – SSL Baseline" and "WebTrust Principles and Criteria for Certification Authorities – Network Security" and (2) "WebTrust for CA - Extended Validation - SSL" (if issuing EV) If ETSI scheme***... (1) ETSI EN 319 411-1 LCP and [DVCP or OVCP]; or (2) ETSI EN 319 411-1 [NCP or NCP+] and EVCP (if issuing EV) |
| Cross-Certified Subordinate CA | Either: (1) Certificate does not include an EKU; or (2) EKU is present and includes id-kp-serverAuth or anyExtendedKeyUsage | Same as above. |
| TLS Subordinate CA or Technically Constrained TLS Subordinate CA | Same as above. | Same as above. |
| Technically Constrained Non-TLS Subordinate CA | EKU is present and does not include id-kp-serverAuth or anyExtendedKeyUsage. | Minimally expected to be audited as defined in Section 8.7 of the BRs (self-audit). |
| All others | N/A | Minimally expected to be audited as defined in Section 8.7 of the BRs (self-audit). |
** CA certificates within PKI hierarchies included in the Chrome Root Store prior to September 1, 2022, MAY have EKU values as described in this table. However, PKI hierarchies added to the Chrome Root Store after September 1, 2022, MUST remain dedicated to only TLS server authentication use cases
*** accepted on a discretionary basis
All Chrome Root Program Participant CAs MUST retain an unbroken, contiguous audit coverage.
Recurring "complete" (i.e., "full", "full system", or "full re-assessment") audits MUST occur at least once every 365 calendar days (or 366 calendar days in a leap year). These audits MUST begin once a CA's key material has been generated and MUST continue until the corresponding root CA's key material has been destroyed or is no longer included in the Chrome Root Store.
The Chrome Root Program may require Chrome Root Program Participants undergo additional ad-hoc audits, including, but not limited to, instances of CA private key destruction or verification of incident remediation.
The failure of a Chrome Root Program Participant to meet the commitments of this policy is considered an incident, as is any other situation that may impact the CA's integrity, trustworthiness, or compatibility.
Chrome Root Program Participants MUST publicly disclose and/or respond to incident reports in Bugzilla, regardless of perceived impact. Reports MUST be submitted in accordance with the current version of this CCADB incident report format and timelines.
While all Chrome Root Program Participants MAY participate in the incident reporting process, the CA Owner whose corresponding certificate is included in the Chrome Root Store is encouraged to disclose and/or respond to incidents on behalf of the Chrome Root Program Participants included in its PKI hierarchy.
If the Chrome Root Program Participant has not yet publicly disclosed an incident, they MUST notify chrome-root-program [at] google [dot] com and include an initial timeline for public disclosure. Chrome uses the information in the public disclosure as the basis for evaluating incidents.
The Chrome Root Program will evaluate every incident on a case-by-case basis, and will work with the CA Owner to identify ecosystem-wide risks or potential improvements to be made that can help prevent future incidents.
Chrome Root Program Participants MUST be detailed, candid, timely, and transparent in describing their architecture, implementation, operations, and external dependencies as necessary for the Chrome Root Program and the public to evaluate the nature of the incident and the CA Owner's response. When evaluating an incident response, the Chrome Root Program's primary concern is ensuring that browsers, other CA Owners, users, and website developers have the necessary information to identify improvements, and that the Chrome Root Program Participant is responsive to addressing identified issues.
Factors that are significant to the Chrome Root Program when evaluating incidents include (but are not limited to):
Due to the incorporation of the Baseline Requirements into CA policy documents, incidents may include a prescribed follow-up action, such as revoking impacted certificates within a certain timeframe. If the Chrome Root Program Participant does not perform the required follow-up actions, or does not perform them in the expected timeframe, the Chrome Root Program Participant MUST file a secondary incident report describing any certificates involved, the expected timeline to complete any follow-up actions, and what changes they are making to ensure they can meet these requirements consistently in the future.
The Chrome Root Program prioritizes and remains committed to promoting public disclosure and discussion of incidents, as they can affect the whole Internet ecosystem, not just Chrome and its users. The Chrome Root Program's sole responsibility when responding to incidents is upholding the safety and security of Chrome's users.
As standard practice, the Chrome Root Program does not:
At any time, the Chrome Root Program may request additional information from a Chrome Root Program Participant using email or CCADB communications to verify the commitments and obligations outlined in this policy are being met, or as updates to policy requirements are being considered. Chrome Root Program Participants MUST provide the requested information within 14 calendar days unless specified otherwise.
CA Owners included in the Chrome Root Store MUST complete the "Chrome Root Program Notification of CA Certificate Issuance" form, made available by emailing chrome-root-program [at] google [dot] com, at least three (3) weeks before a CA in the corresponding hierarchy issues a CA certificate that:
Examples of the above use cases include cross-certificates issued to CA Owners not represented in the Chrome Root Store and Externally-operated CA certificates.
Such CA certificates MUST NOT be issued without the expressed approval of the Chrome Root Program.
No other notification or approval is required.
Chrome Root Program Participants MUST NOT assume trust is transferable.
Where permissible by law, Chrome Root Program Participants MUST notify chrome-root-program [at] google [dot] com at least 30 calendar days before any impending:
Not limited to the circumstances above, the Chrome Root Program reserves the right to require re-application to the Chrome Root Store.
Chrome Root Program Participants are expected to maintain awareness of, and where relevant, actively engage in public discussions concerning CA practices, policy developments, and incidents, within minimally the following public forums:
Awareness of, and participation in, other key industry and community forums is encouraged.
The following requirements are effective immediately, unless explicitly stated as otherwise.
Applicants MUST accurately describe the policies and practices of their CA(s) within a single CA policy document that is:
The immediately above requirements do not prohibit Applicants from maintaining additional policy documents, which may also be considered authoritative by other stakeholders. However, the consolidated policy document made available to the Chrome Root Program MUST NOT conflict with any additional policy documents that might exist for the corresponding PKI hierarchy.
The Chrome Root Program only accepts CCADB Root Inclusion Requests from Applicant PKI hierarchies with corresponding root CA key material generated within five (5) years of application to the Chrome Root Store.
Applicants MUST submit written evidence to the CCADB identifying the date(s) of the key generation ceremony and an attestation to the Applicant's adherence to the requirements defined in Sections 6.1.1.1 ("CA Key Pair Generation") and 6.2 ("Private Key Protection and Cryptographic Module Engineering Controls") of the Baseline Requirements from a Qualified Auditor using an approved format, in accordance with the table below.
| Audit Scheme | Qualified Auditor Criteria | Report Format Criteria |
|---|---|---|
| WebTrust | an enrolled WebTrust practitioner | WebTrust "Reporting on Root Key Generation" report |
| ETSI | a member of the Accredited Conformity Assessment Bodies' Council (ACAB'c) | ACAB'c Key and Certificate Ceremony Audit Attestation Letter |
If key material is not used to issue a self-signed root CA certificate on the same date it was generated, Applicants MUST present written evidence from a Qualified Auditor, attesting that keys were minimally protected in a manner consistent with the requirements defined in Section 6.2 ("Private Key Protection and Cryptographic Module Engineering Controls") of the Baseline Requirements from the time of generation to the time the self-signed certificate was issued. Publicly-accessible links for these documents MUST be disclosed to the CCADB.
The Chrome Root Program will only accept CCADB Root Inclusion Requests from Applicant PKI hierarchies that are dedicated to TLS server authentication certificate issuance.
To qualify as a dedicated TLS server authentication PKI hierarchy under this policy:
All unexpired and unrevoked subordinate CA certificates included in an Applicant PKI hierarchy MUST be integrated with an automation solution, minimally compliant with either Section 1.3.3.1.1 ("ACME Solutions") or Section 1.3.3.1.2 ("Non-ACME Solutions"). Functionally, this means that every TLS server authentication certificate profile offered by the PKI hierarchy MUST be capable of being issued and renewed using an automation solution. CA Owners MUST attest that this requirement is met for each Baseline Requirements certificate policy OID the corresponding Applicant PKI hierarchy issues through a disclosure in the CCADB on the root certificate record of each CA certificate intending to be included in the Chrome Root Store.
For each Baseline Requirements certificate policy OID an Applicant intends to issue, the Applicant MUST disclose at least one (1) automation solution to the CCADB. For each such OID, the Applicant MUST use a disclosed automation solution to issue "Automation Test Certificates" to demonstrate its automation capabilities. Automation Test Certificates MUST be renewed at least once every 30 calendar days; however, at any point, the Chrome Root Program may request more frequent renewal. At least one (1) valid Automation Test Certificate corresponding to each Baseline Requirements certificate policy OID MUST be served by a publicly accessible website whose URL is disclosed to the CCADB on the corresponding intermediate certificate record. Applicants are encouraged to issue "Short-lived Subscriber Certificates," as introduced in Version 2.0.1 of the Baseline Requirements, for the Automation Test Certificates.
Applicant PKI hierarchies MUST provide evidence of at least one (1) complete audit by disclosing the applicable ETSI Audit Attestation Letter(s) or WebTrust Assurance Report(s) to the CCADB before submitting a CCADB Root Inclusion Request to Google Chrome. The initial complete audit SHOULD cover a period of at least 180 calendar days.
For Applicant PKI hierarchies subject of a CCADB Root Inclusion Request submitted to Google Chrome:
If accepted into the Chrome Root Store, Applicant PKI hierarchies MUST continue this practice for the duration of its inclusion.